Multiplayer Game Basics
If you’ve been fortunate
enough to play a multiplayer network game with your friends, you already
know how much fun it can be. In many ways, outwitting a real person is
much more fun than competing against a computer player. The reality of
going head-to-head with another person can change the whole perspective
of a game. I have yet to see a single-player game that evokes the same
level of emotion and excitement as is generated from the human factor in
multiplayer games.
There are endless
possibilities for multiplayer games involving both cooperation and
competition among human players. Regardless of the scenario, when real
people are involved, a certain synthesis of ideas and reactions takes
place that just isn’t possible with computer players. It’s then up to
game designers like you and me to chart the course and dream up new ways
for people to interact with each other through games. Now consider the
uniqueness of being able to play a multiplayer game on a mobile phone
over a wireless network connection from anywhere. This is what many of
us have been waiting for in the “wireless revolution” we’ve been hearing
so much about for the past few years.
Before you get into the
design strategies for network games, it’s important to understand the
fundamental types of network games. The communication design can be
affected dramatically by the way that game play progresses, which is
determined by the type of game. Mobile network games can be generally
broken down into two types: turn-based and event-based. Most games
should easily fall into one of these two categories.
Turn-Based Games
Turn-based games are
games in which each action in the game is based on a player’s turn. The
classic checkers, chess, and Connect 4 games are good examples of
turn-based games because you are allowed to make a move only when it is
your turn. Sure, you are free to think about your move during the other
player’s turn, but in the context of the game you can take action only
during your turn.
Most
turn-based games are board games or card games, or simple games played
on paper such as Tic-Tac-Toe. Although they have a much slower pace than
action games, turn-based games are very popular and well suited for
networking.
Knowing that
turn-based games revolve around whose turn it is, the network
communication design is greatly simplified. Only one player can interact
with the game at a time. Even though multiple players are technically
playing the game, only one player is allowed to make a move at a time.
The other players must wait their turns before they can do anything. In
this way, the game can be designed so that all the players are in a wait
state until it becomes their turn. In a two-player game such as Connect
4, the turns just move back and forth between the players.
Event-Based Games
Event-based games are
games that are dictated by input events that can occur at any time.
Event-based games are much more open-ended than turn-based games. In an
event-based game, any player can interact with the game at any time,
resulting in an input event. The flow of the game is dictated by the
input events rather than turns. As a matter of fact, there is no concept
of a “turn” in an event-based game. Event-based games include basically
all games that don’t revolve around turns; examples range from
first-person shoot-em-ups such as the popular Halo and Doom series to
strategy simulators such as Age of Empires. In the network modes of
these games, any player can act independently of any other players,
generating anywhere from no events to a massive flood of events.
If you
haven’t suspected, the communication design for event-based games is
much more complex and difficult to implement than that for turn-based
games. More importantly, event-based game communication typically
requires a much wider bandwidth, because more information is usually
being transmitted. It’s probably safe to say that each different
event-based game you create will have a unique solution because there
are so many trade-offs to be made in regard to determining the best way
to design the network communication logic. In a game such as Halo 2 or
Doom 3, think about how many things are going on—and even more
important, notice how quickly things are happening. Any change in the
game from one player’s perspective must be communicated to all the other
players in some form.
Gamer’s Garage
Because
bandwidth is a big consideration in event-based games, it is currently
very challenging to develop event-based games on mobile phones. As
mobile network speeds increase, this challenge will diminish, but
developing efficient networking code is widely considered one of the
most challenging aspects of game development, and even more so for
mobile games. |
An
event-based game never “allows” the players to do anything, as in
turn-based games. The game just sits back and waits for the players to
generate input events. Players can generate these events as often or as
seldom as they want, fully independent of the other players. This is
what enables you to patiently wait behind a corner while another player
runs by haphazardly at full speed. Some people never learn!
Network Game Problems and Solutions
Now that you know which
type of network games you are dealing with, let’s look at some of the
common problems you will encounter in a mobile network game design. The
overriding concern to be dealt with in designing network games is
maintaining synchronization. Synchronization refers to how multiple game
instances running on different phones maintain the same game state
information. Remember that each player is running a separate instance of
the game, but the overall goal is to make each of these different
instances function logically as one game. All the internal data
structures modeling the game’s state should match exactly on each
player’s system.
You can best
understand this concept by looking at an example of what can happen when
synchronization is lost. Suppose that two players are playing a network
adventure game similar to one of the games in the popular Diablo
series. As they are walking along together, they run across a demon.
Player 1 is a little more assertive and starts fighting the demon.
Player 2 is low on energy and decides to just sit in the shade and
watch. When Player 1 finishes off the demon, Player 2 somehow must be
notified, and not just as a matter of convenience; any change in the
game that potentially can affect other players must be communicated to
them.
Another common problem in
regard to synchronization involves using random values in games. It is
fairly common for games to place some objects randomly when a game
starts, such as treasure or even monsters. Sometimes games use random
events just to make things vary a little from game to game. In network
games this creates big problems unless each game instance uses the exact
same random values as all the other instances. It would totally blow
the synchronization for each game to have things going on randomly with
respect to each instance. The point here is that many seemingly
insignificant things, such as generating random numbers, can cause major
headaches in a network game environment.
Now that you
understand the problems, let’s move on to some solutions. There are many
different approaches to designing network game communications, and they
all must somehow address the problem of keeping each player’s instance
of the game synchronized with all others. You’re going to focus on two
basic types of network game synchronization strategies: state
synchronization and input synchronization.
State Synchronization
State
synchronization is a communication method by which each game instance
communicates its current state to the other instances. The state
synchronization method is very robust because there is no chance for
information loss; everything regarding the current state of the game is
sent to the other instances. In a two-player space battle game, for
example, the position and speed of all the planets, asteroids, ships,
and bullets would be sent as the current state of the game.
Gamer’s Garage
Because
of limited bandwidth on mobile phones, state synchronization represents
the biggest challenge to developing networked mobile action games. |
Sounds good so far. But
what about a more complex game, such as a role-playing adventure game
with entire virtual worlds with which the players constantly are
interacting? Sending the state of the entire game starts looking a
little more difficult because of the vast amounts of information
required to model the game state. And don’t forget about the bandwidth
limitation you learned about earlier, which keeps you from being able to
send loads of information between mobile phones. Knowing this, it’s
easy to see that state synchronization is a fairly messy network
communication solution. Although state synchronization is functionally a
very solid network solution, technically it’s not always feasible.
Input Synchronization
Input
synchronization is a communication method in which each game
communicates the input events of its player to the other game instances.
Using input synchronization, each time a player generates input events,
such as pressing keys, the game broadcasts these events to the other
games. If you think about the space battle game example from before,
rather than send the state of all the objects, the game just sends the
key input events generated by the player. Each game then handles each
remote (virtual) input from the other games in a similar manner as it
handles its own local player’s input.
There has to be a catch,
right? Of course there’s a catch! Input synchronization works fine as
long as all the changes in the game are dictated solely by the players’
inputs. Practically speaking, this rarely is the case except in very
simple games. There are usually random effects in a game, such as
placement of background objects. These random effects wreak havoc on
games relying on input synchronization because they aren’t affected by
player input and therefore are never communicated between games.
If
you happen to have a game in which the entire play flow is dictated by
player input, input synchronization is for you. Otherwise, you’ll have
to come up with another solution. Can you think of any games that are
dictated entirely by user input? Give up? It ends up that most
turn-based games are driven completely by user input. So you usually can
implement network support for turn-based games by using input
synchronization.
A Hybrid Solution
Now that I’ve painted a
pretty bleak picture of network game design, I’ll let you in on a
practical reality in mobile network game design: You usually will have
to use some combination of the two methods mentioned. This hybrid
solution would include elements of both state and input synchronization.
Using the space battle game example one more time, you could send the
user inputs back and forth using input synchronization, and then use
state synchronization to send random events such as initial meteor
positions. You still don’t necessarily need to transmit the entire state
of the game, just the aspects of the game state that can’t be figured
out by each instance on its own. In other words, random events need to
be transmitted to each game instance.
If you run across a
gaming scenario that doesn’t fit well within any of these approaches,
you might figure out a communication technique of your own to add to or
replace one of these. Network gaming is a unique area of game
programming that leaves room for very few general techniques. You
usually have to come up with hybrid solutions that draw on what you’ve
learned, combined with new ideas you dream up along the way.